home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: jbuck@Synopsys.COM (Joe Buck)
- Newsgroups: comp.std.c++
- Subject: Re: Give operator. a chance
- Date: 26 Jan 1996 00:05:36 GMT
- Organization: Synopsys Inc., Mountain View, CA 94043-4033
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <4e90k4$gqr@hermes.synopsys.com>
- References: <3102AD11.1663@et.se> <4e0nc3$4dp@engnews1.eng.sun.com>
- NNTP-Posting-Host: taumet.eng.sun.com
- Content-Type: text
- X-Nntp-Posting-Host: deerslayer.synopsys.com
- Content-Length: 5058
- X-Lines: 93
- Originator: clamage@taumet
-
- clamage@Eng.Sun.COM writes:
- >It's hard for me to imagine that anyone could come up with new arguments
- >in favor of operator.() that also answer the objections to it. If you think
- >you can do so, go ahead, but do yourself and everyone else a favor and
- >acquaint yourself with the discussion that has already occurred. Note
- >especially the arguments in the ARM and D&E against "operator dot".
-
- Since I want a language standard soon, I'll live without operator dot.
- But I will object to attempts to rewrite history.
-
- Please note that in D&E Stroustrup does not argue against overloaded
- operator dot, but rather against specific proposals. Unfortunately,
- Stroustrup's arguments against specific overloaded operator dot proposals
- are rather embarrassing for him, not up to his usual standard of skillful
- writing. But if you wish, I will answer them.
-
- In D&E, section 11.5.2, he objects that obj.m already has a meaning,
- and that overloading operator. would thus make the language mutable,
- but he admits that the rule is broken for operator= and operator&.
-
- The second objection, that overloading both operator. and operator->
- would cause problems, is also easily dismissed. The answer is simple:
- "don't do that". One overloads operator. to make a class that has
- reference semantics. One overloads operator-> to make a class that
- has pointer semantics. It would be bad design to make an object that
- works like both a pointer and a reference, so the fact that such classes
- are difficult to write because you can't get to their members is not an
- issue.
-
- Stroustrup then comes to the Adcock proposal. He points out its benefits
- in implementing delegation (a "handle" class or a "proxy" class). He
- then objects that overloading operator. does not do the complete job
- (he says "doesn't have the right effect") because there are cases
- where the dot is not mentioned (when overloaded operators are used)
- so that there is still the need to write forwarding functions for
- them. He states "this is clearly tedious". But the tedium is
- substantially reduced with respect to what it is now (no forwarding
- functions for normal member functions, only overloaded operators).
- Since many classes don't overload *any* operators, this tedium reduces
- to zero.
-
- Note that the example he chooses stacks the deck against the Adcock
- proposal, in that the proxy class has one member function and two
- overloaded operators, meaning that overloaded operator dot saves only
- one forwarding function. But I have several examples in the project
- I am currently working on where there are eight to twelve functions
- to be forwarded and no overloaded operators. I need to write inline
- functions for every last one of them, and all changes have to be
- done in two places.
-
- Stroustrup then describes a *new* proposal in which operator. has the
- magic behavior of also forwarding overloaded operators. There was
- evidently disagreement in the committee over which is better (I think the
- Adcock proposal is cleaner myself, though I could live with this one).
- Not mentioned here, but mentioned in some comp.std.c++ discussions,
- is that people objected to that one because of the "surprise factor"
- (I wrote no dot, why is operator. being called?).
-
- He next objects that overloading operator. breaks the equivalence of
- a.m and (&a)->m. Sorry, Dr. Stroustrup, there is no such equivalence,
- thanks to overloaded operator & . The symmetry was broken by the
- creation of "smart pointers". Symmetry can be restored by dropping
- operator& and operator->, or by adding operator dot.
-
- He then points out that you could restore this symmetry when overloading
- operator. by generating automatic overloads operator& and operator-> to
- match operator. and immediately points out that this would cause problems.
- But this is a straw man. Never before in C++ did overloading one operator
- change others. Overloading += doesn't create a matching overload for + to
- force a consistent meaning for addition. Why raise hoops for
- extensions that the core language cannot meet? Why make the language
- inconsistent in this way?
-
- "We are thus left in a quandry: we can either maintain the a.m and
- (&a)->m equivalence or have access to members of the smart reference,
- but not both". False. There is already operator&. There is no
- guaranteed equivalent in the language of a.m and (&a)->m today,
- with or without any extensions. We can exploit the broken symmetry and
- allow access to members of the smart reference with (&a)->m.
-
- Stroustrup proposes that operator. only forward to the resulting class
- for a.m if the object itself doesn't have a member m. I dislike that
- approach; it is unnecessary since (&a)->m accesses it, and since
- the class is going to present itself as a disguised reference object
- in any case, only private code is going to mess around with the object's
- own members. In member functions, one would merely write "m".
-
-
- --
- -- Joe Buck <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
-
- Work for something because it is good,
- not just because it stands a chance to succeed. -- Vaclav Havel
-
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-
-